Many organizations are embracing the paradigm of Model Based Development in their production processes. “Model Based Development” refers to the practice of specifying, analyzing, and implementing systems using a common “model” consisting of a set of block diagrams and associated objects. System implementation typically entails automatically generating code for portions of the model, in particular portions of the system intended to run on embedded hardware.
Graphical modeling environments are an example of software applications that may enable a user to model dynamic systems i.e., systems whose outputs change over time, using a graphical model, such as a block diagram. Some graphical modeling environments also enable simulation and analysis of models. Simulating a dynamic system in a graphical modeling environment is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts time-based relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system over a specified time period is simulated using the information entered into the graphical model. In this step, the graphical model is used to compute and trace the temporal evolution of the dynamic system outputs (“execute the graphical model”) and automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (“code generation”).
Block diagrams are graphical entities having an “executable meaning” that are created within graphical modeling environments for modeling a dynamic system, and generally comprise one or more graphical objects. For example, a block diagram model of a dynamic system is represented schematically as a first collection of graphical objects, such as nodes, which are interconnected by another set of graphical objects, generally illustrated as lines, which represent logical connections between the first collection of graphical objects. In most block diagramming paradigms, the nodes are referred to as “blocks” and drawn using some form of geometric object (e.g., a circle, a rectangle, etc.). The line segments are often referred to as “signals”. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition of the relationship between the signals and the state variables is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a “port.” The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination node of this signal read from the signal when their system equations are being solved. In some instances, the nodes of a system represent actual computing platforms, such as processors, field programmable gate arrays, application specific integrated circuits, programmable logic devices, and hardware devices, such as memory, buffers, adaptors, and physical interface ports. The lines between such nodes represent the interfaces between the devices. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
Traditionally, when designing a system from which code will be generated, in order to generate the proper code, a target computing platform must be selected. This selection informs the graphical modeling environment which processor, FPGA, ASIC or the like, the system is to operate on or with. Typically, target computing platforms operate on data acquired through hardware input devices and emit the resultant processed through hardware devices, therefore the interfaces to the I/O devices are integral parts of the system design. Consequently, device driver code for all the devices of the modeled system is generated to operate on the “targeted” computing platform. An example of this can be seen in the block diagram model 100 of FIG. 1. In this example the block diagram contains an Analog-to-Digital Converter (ADC) 110, a processing block 120, and Digital-to-Analog Converter (DAC) 130. The ADC 110 provides digitized data that is passed to the processing block 120. The digitized data is processed by the processing block 120 once the ADC 110 triggers the processing via an interrupt (denoted by dotted line), and then the resultant processed data is sent to the DAC block. The target computing platform for this system, as indicted by the icon 140 in the bottom left corner, is a C6416 DSP processor which is part of the Texas Instruments C6000 DSP family. The ADC 110 and DAC 130 are also specific to the Texas Instruments device TLV320AIC23, as indicated by the block names. As such, the ADC 110 and DAC 130 blocks are therefore “hard-coded” for the TLV320AIC23, and cannot work for any other device. Likewise, other devices, such as an analog-to-digital converter or digital-to-analog converter from another manufacturer, require device and computer platform specific blocks in order for the proper device drivers to be generated for a C6416 DSP.
One problem with this approach is that in order to create the driver code for a specific device to be controlled by a “targeted” computing platform, the specific device must be part of a provided library of recognized devices for the proper driver code to be generated for the targeted platform. That is, in order for driver code to be generated for a device, such as an analog-to-digital converter, to be controlled by a targeted platform, the analog-to-digital converter must be in the library of “known” devices for the targeted platform so that the graphical modeling environment can generate the required driver code. This means if a device to be controlled is not in the library of supported devices for a specific target platform then driver code cannot be automatically generated for the device. Thus a user is limited to using only the devices that are supported for a given target, or else the user must obtain new device driver blocks, either relying on a vendor to provide the driver blocks or creating them from scratch.
What is needed is a method for creating any number of device drivers for a target platform that is not restricted to the original library of supported devices for each target computing platform.